The approaches described in this section could be pursued, but are not necessarily approaches that have been previously conceived or pursued. Therefore, unless otherwise indicated herein, the approaches described in this section are not prior art to the claims in this application and are not admitted to be prior art by inclusion in this section.
Border Gateway Protocol (BGP) is a path vector routing protocol for inter-Autonomous System routing. The function of a BGP-enabled network element (a BGP host or peer) is to exchange network reachability information with other BGP-enabled network elements. The most commonly implemented version of BGP is BGP-4, which is defined in RFC1771 (published by the Internet Engineering Task Force (IETF) in March 1995).
To exchange routing information, two BGP hosts first establish a peering session by exchanging BGP OPEN messages. The BGP hosts then exchange their full routing tables. After this initial exchange, each BGP host sends to its BGP peer or peers only incremental updates for new, modified, and unavailable or withdrawn routes in one or more BGP UPDATE messages. A route is defined as a unit of information that pairs a network destination with the attributes of a network path to that destination. The attributes of the network path include, among other things, the network addresses (also referred to as address prefixes or just prefixes) of the computer systems along the path. In a BGP host, the routes are stored in a Routing Information Base (RIB). Depending on the particular software implementation of BGP, a RIB may be represented by one or more routing tables. When more than one routing table represents a RIB, the routing tables may be logical subsets of information stored in the same physical storage space, or the routing tables may be stored in physically separate storage spaces.
As defined in RFC1771, the structure of a BGP UPDATE message accommodates updates only to Internet Protocol version 4 (IPv4) unicast routes. The Multiprotocol Extension for BGP defined in RFC2858 (published by IETF in June 2000) accommodates updates to routing information for multiple Network Layer protocols, such as, for example, Internet Protocol version 6 (IPv6), Internetwork Packet eXchange (IPX), Appletalk, Banyan Vines, Asynchronous Transfer Mode (ATM), X.25, and Frame Relay. RFC2858 introduced two single-value parameters to accommodate the changes to the BGP UPDATE message structure: the Address Family Identifier (AFI) and the Subsequent Address Family Identifier (SAFI).
The AFI parameter carries the identity of the network layer protocol associated with the network address that follows next in the path to the destination. The SAFI parameter provides additional information about the type of the Network Layer Reachability Information that is included in a BGP UPDATE message, and the values defined for this parameter usually indicate a type of communication forwarding mechanism, such as, for example, unicast or multicast. While some of the AFI and SAFI values are reserved for private use, the AFI and SAFI values that can be commonly used by the public must be assigned through the Internet Assigned Numbers Authority (LANA). The AFI/SAFI combination is used by the software implementations of BGP to indicate the type of the BGP prefix updates, what format the prefix updates have, and how to interpret the routes included in the BGP UPDATE messages.
However, the AFI/SAFI hierarchy is a tight structure that cannot be easily modified to accommodate changes. If a new type of addresses, which does not conform to the current hierarchy of a major family address and a subsequent family address, is ever needed, there is no good way to convey updates to routes that include addresses conforming to such new type of addresses because the new type of addresses may not be adequately describable by using only AFI and/or SAFI values.
For example, with the proliferation of different types of network traffic, such as streaming video and voice-over-IP, there may be different types of addresses in a network that belong to the same address family. A network may carry audio, video, and regular data traffic in an IPv4 address network. In this case, it is desirable to store network routes for the different types of traffic in separate routing tables to achieve faster route updating. However, since the different routes are represented by the same address family (such as, for example, an AFI/SAFI combination indicating IPv4 unicast), current implementations of BGP cannot distinguish among these routes, and will have to put them in the same routing table. Thus, the AFI/SAFI combination proves inadequate at least to differentiate between routes that carry different types of network traffic.
One past approach that accommodated a new address family in a BGP implementation was assigning of a new SAFI value for identifying Virtual Private Network (VPN) addresses. In this approach, the implementation of BGP was also modified to specifically deal with the prefixes conveyed by a BGP UPDATE message for updates to routes that included VPN addresses.
However, this approach has several disadvantages. One problem is that upon receiving a BGP UPDATE message, the whole route must be extracted from the message before it can be determined to which routing table the updates would go. Another problem with using this approach to accommodate a new address family is that formal changes to the software implementation of BGP and to the BGP UPDATE message structure are needed every time a new address family is defined by assigning a new AFI and/or SAFI value.
Another problem with updating routes in BGP by using the AFI/SAFI hierarchy is that currently BGP does not support sending an IPv6 address prefix in a NEXT_HOP PATH attribute that is included in a BGP UPDATE message for an IPv4 route. Currently, BGP defaults the NEXT_HOP attribute values to the same address family to which the BGP UPDATE message is targeted. The reason is that a 16-byte IPv6 address cannot be stored in a 4-byte IPv4 address space, and consequently, BGP cannot be used to provide route updates for IPv4 routes in which the next hop in the route is an address in a “pure” IPv6 network.
Based on the foregoing, there is a clear need for techniques providing routing table updates in BGP for routes including addresses from newly-defined address types or address families, while not requiring any modifications to the software implementation of BGP itself. Further, there is a clear need to provide in BGP updates to IPv4 routes for which the next hop in the route is an address in an IPv6 network.